Application install and layout syncing

ABSTRACT

Embodiments described herein relate to synchronizing configuration information between devices associated with a user. The synchronized configuration information can relate to application installations and uninstallations as well as to user modifications to user interfaces for managing and invoking the applications. For example, layouts of application representations provided by respective application launchers on a user&#39;s respective devices are kept automatically synchronized when the user modifies any of the layouts. Installations and uninstallations are similarly synchronized between the user&#39;s devices. Installations and uninstallations that might stem from synchronization may be circumscribed in various ways, such as by allowing the user to specify whether specific applications are to be installed/uninstalled only on specific devices or globally, by filtering propagation of synchronization updates according to hardware or software features and incompatibilities, or others.

RELATED APPLICATIONS

This application is a continuation patent application of copending application with Ser. No. 13/904,929, (attorney docket no. 338761.01) filed May 29, 2013, entitled “APPLICATION INSTALL AND LAYOUT SYNCING”, which is still pending. The aforementioned application(s) are hereby incorporated herein by reference.

BACKGROUND

Modern computing devices are often able to be customized and configured by users. Such customizing may involve installing and uninstalling executable applications, arranging application tiles or icons within a graphical user interface such as an application launcher (or other type of graphical user shell or application), changing the appearance of user interface elements, and so forth. In addition, an individual person may have a variety of computing devices that the individual regularly uses. Sometimes a user may install and use some of the same application programs (i.e., applications that have highly similar user interface and algorithms) on the user's computing devices. In addition, the computing devices may have hardware or software incompatibilities that necessitate installing different revisions or platform-specific versions of the same applications, perhaps only on partially intersecting subsets of the user's computing devices.

As the inventors have observed, a user may invest time in configuring one computing device among a variety of computing devices controlled by the user. For the user to create parallel experiences when using each of their computing devices, that invested time may be invested for each of the user's computing devices. This duplicative customizing for different devices can be burdensome to the user. For example, a process of manually installing applications and customizing the layout and appearance of a user interface may need to be repeated across a mix of computing devices. Furthermore, perhaps due to hardware or software limitations of platforms or applications, a user's preferences and requirements may be only partially implemented, to varying degrees, on some of the user's computing devices. This may task the user with manually keeping track of what experience-synchronizing tasks are needed for which devices.

In view of these inventor observations, techniques related to synchronizing user configurations among the user's computing devices are discussed below.

SUMMARY

The following summary is included only to introduce some concepts discussed in the Detailed Description below. This summary is not comprehensive and is not intended to delineate the scope of the claimed subject matter, which is set forth by the claims presented at the end.

Embodiments described herein relate to synchronizing configuration information between devices associated with a user. The synchronized configuration information can relate to application installations and uninstallations as well as to user modifications to user interfaces for managing and invoking the applications. For example, layouts of application representations provided by respective application launchers on a user's respective devices are kept automatically synchronized when the user modifies any of the layouts. Installations and uninstallations are similarly synchronized between the user's devices. Installations and uninstallations that might stem from synchronization may be circumscribed in various ways, such as by allowing the user to specify whether specific applications are to be installed/uninstalled only on specific devices or globally, by filtering propagation of synchronization updates according to hardware or software features or incompatibilities, or others.

Many of the attendant features will be explained below with reference to the following detailed description considered in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein like reference numerals are used to designate like parts in the accompanying description.

FIG. 1 shows an example of a multi-user multi-device cloud-oriented operating environment.

FIG. 2 shows a user computing device identified by a corresponding device identifier.

FIG. 3 shows two of a user's computing devices.

FIG. 4 shows an example system design for synchronizing configuration information among a user's devices.

FIG. 5 shows examples of configuration synchronization data and an example of a do-not-install list.

FIG. 6 shows an example of installation information synchronization.

FIG. 7 shows an example of layout information synchronization.

FIG. 8 shows an example computing device on which embodiments may be implemented.

DETAILED DESCRIPTION

Embodiments described below relate to synchronizing user configurations among the user's computing devices. Such configurations may include installations and uninstallations of applications as well as layouts of user interfaces, among others. This description of inventive embodiments will begin with an overview of cloud-linked computing and computing devices used therefor. Next, synchronizing configurations across devices will be discussed. This will be followed by implementation details and examples.

FIG. 1 shows an example of a multi-user multi-device cloud-oriented operating environment. Users 96 may use or control respective sets 98 of computing devices 100. Each user may have a user credential, user account, user identity 102, or some functional equivalent for distinguishing identity across computing devices forming and using a computing cloud 104. Account names, email accounts or addresses, and website accounts, are examples of user identities 102. Other information that can uniquely identify users can also serve as a user identity, such as a public key, a digitally signed certificate, a cookie, a hashtag, a biometric, etc. Such will be referred to as user identities 102.

The computing cloud 104 may be, for example, a suite of cooperating computing services, for example web services. The services may be accessed over a data network using a protocol stack including levels or layers of abstraction such as a transport layer, a network layer, an application layer, etc. Packets at one layer of the protocol stack may encapsulate packets or messages of another layer. At an application layer, packets might carry application-level information, for example invocations and results when applications installed by users 96 interact via a network with resources in the computing cloud 104 and when servers that form the cloud 104 interact via network to coordinate the various network resources or network-accessed computing services.

The computing devices 100 or servers providing these services or resources may have infrastructure that coordinates and facilitates cooperation among the servers, for example midware, clustering management, standby servers, data mirroring, virtual machine management, migration software, database engines, and so forth. Rudimentary computing clouds 104 may lack many or most of the features mentioned above. For example, the computing cloud 104 might be a single hardware server providing one or two software services such as an identity management or account service 106 and an application service 108. These services as well as possibly user computing devices 100 might use a data storage service, which is not shown in FIG. 1.

The account service 106 manages the user identities 102 that are used within the cloud 104 and on the user computing devices 100. The user identities might be stored in a table 110 or the like. For discussion herein, each user is assumed to have at least one user identity 102 that is unique at least within the cloud 104. A given user may have multiple computing devices that implicitly form a device group 98; a group 98 of user computing devices that use a same user identity 102 for presumably a same user when interacting with the cloud 104. As discussed further below, an embodiment may be implemented that allows a user to explicitly specify device subgroups and manage configuration synchronization on a by-subgroups basis.

Returning to FIG. 1, the account service 106 may also track user computing devices in a table or data store 112 of environment or device identifiers 114. A device identifier 114 uniquely identifies a hardware/software unit that might autonomously execute applications installed therein. A device identifier 114 might identify a user computing device, a hardware component of a computing device, an operating system instance, a virtual machine, an execution sandbox or application-virtualization environment, to name some examples.

Description herein that refers to a “user computing device”, a “user device”, or the like, in the context of synchronization, is deemed to also refer to any of a variety of general hardware/software units within which applications can be separately installed, executed, and user-configured. User devices might therefore encapsulate other user devices. In one embodiment, a user computing device is indeed a hardware device typically having a processor, non-volatile storage to store applications executed by the processor, a display, an operating system (or a software environment), network communication capabilities, and/or a user input device. The meaning of “computing device” refers to virtual machines or hardware machines such as laptops, workstations, smartphones, portable media players, tablets, set-top devices, electronic gaming devices, and others.

FIG. 2 shows a user computing device 100 identified by a corresponding device identifier 114. The computing device 100 may provide one or more user-configurable graphical user interfaces (GUIs) 116 for the user to interactively manage applications 118 (e.g., install/uninstall), interact with applications 118, or launch (newly execute and/or bring to the fore) windows 120 of the applications 118. Such a GUI 116 might be a lightweight client or web browser, a system GUI provided by or closely integrated with a windowing system 122 and/or an operating system 124, or an instance of a locally executing application 118 which might or might not be installable or uninstallable or replaceable by a user. The user-configurable GUI is displayed to the user by a display 126 of, or from a graphics signal outputted by, the computing device 100. The display 126 may be locally connected to the computing device 100 by way of a graphics port or display adapter of the computing device 100, via a local bus of the computing device 100, or by various network protocols designed to simulate bus-type connectivity.

The windowing system 122 may be integrated with or closely coupled with the operating system 124. For purposes herein, distinctions between these components are not significant; an operating system itself may be considered to be a windowing system. The windowing system 122 may have functionality that is known in the computing arts, such as handling input events (e.g., touches/strokes, clicks, keypresses, mouse drags, etc.) inputted by a user with various types of input devices. The windowing system 122 also manages the windows 120 by handling related events or user interactions such as closing windows, moving windows, resizing windows, directing input to windows, rendering multiple concurrent windows, and others. The windowing system 120 may also provide a background, system controls (user interface elements), or other GUI elements not specific to an application. As noted above an application launcher is an example of a GUI 116 or element thereof.

An application launcher is sometimes referred to as a “launcher”, “switcher”, a “graphical user shell”, etc. An application launcher may be any software elements for allowing a user to interactively perform application-related tasks such as installing/uninstalling applications, opening/closing applications, toggling between application windows, configuring properties or behaviors of applications, displaying content from an application perhaps when the application is not open, and/or others.

An application launcher may be user-configurable, for instance having user-selected or user-arranged application representations 128 (e.g., icons, tiles presenting dynamic content) representing corresponding applications. As shown in the example of FIG. 7, an application launcher may be a pannable surface or may have navigable display areas (pages) that contain application user-arranged representations 128.

The application representations 128 may be part of a user-configurable layout of the application launcher; application representations may have user-configurable size, display order or position, appearance attributes such as colors or a graphic symbol, presence/absence, groups, categories, keywords, or other features. Collectively, these types of user-configurable parameters might also be termed “launcher layout configuration or settings” or “application representation layout/selection/arrangement information”.

An application launcher may also include dashboard-like features such as a clock, a logout mechanism, network status information, system or application notifications, and so forth (some of which might be applications or gadgets). Activation or configuration of some such features may also be considered user-configurable launcher layout. For example, several types of settings could make use of synchronized application lists such as settings to allow/disallow applications to perform certain functions, or enable a list of applications that can function in the background, or applications that can present details on a lock screen type interface.

In some embodiments an application launcher is displayed or undisplayed by a user command, may be displayed in a full-screen mode, may partly overlay application windows, may be managed as a window object by the windowing system, may automatically hide or retract responsive to a user interaction, may be displayable by multiple displays of a computing device, etc. In some embodiments, an application launcher is undisplayed when a graphic application representation is actuated to open an application window; the opened application window may fully or partly displace or cover the application launcher. As discussed further below, such configurable features, in particular user-configurable features, may be automatically configured by synchronization between a group or subgroups of a user's computing devices.

An application representation 128, in addition to being a conduit for a user to open/close its application, to install/uninstall its application, or to switch-to or select its application, an application representation 128 may be a unit of content or link to content associated with a corresponding application, such as a Uniform Resource Locator (URL) associated with a browser application, a document or file, a link to a user profile or account that can be opened by a social network application, to name a few examples. As used herein, the term “launch” refers to both initially opening an application (e.g., starting a new process) as well as well as opening (displaying) the already-running (possibly dormant) application window for an application.

In addition to layout synchronization, embodiments herein may synchronize installations or uninstallations of applications between a user's computing devices or subgroups thereof. Referring again to FIG. 1, the application service 108 may be a network service or resource that transmits to a user's computing devices application packages, installation-enabling information, or other forms of application installs 140 such as install links, executables, setup programs, etc. The application service 108 may reside in a computing cloud other than the computing cloud 104 that has the account service 106.

The application service 108 or application store may function as a marketplace, may be curated by a controlling entity or organization, and may provide for online digital distribution of applications and possibly other content. Examples include the Apple™ App Store, Google Play™, the Windows Store™, and the Amazon Appstore™. The application service 108 may maintain a catalog 142 of applications identified by application identifiers. The account service 106 and/or the application service 108 may also maintain application associations 144 indicating which user identities have previously installed or purchased which applications. In either case, the account service 106 and the application service 108 may cooperate to track which applications have been installed by which users. Such information about an application may persist even when the user has uninstalled the application from one or more of the user's computing devices.

FIG. 3 shows two of a user's computing devices; a first user device 100A and a second user device 100B. For discussion, the two user devices represent any two or more arbitrary user computing devices 100 described above. The first and second user devices 100A, 100B and the cloud 104 each have synchronization software for synchronizing information between the cloud 104 and the first and second user devices 100A, 100B.

In one embodiment, the components are part of a generic synchronization framework that enables synchronization of any data specified for synchronization. Embodiments described herein synchronize user-configurable layout and/or application installation information (“configuration information” for brevity). As with most synchronization systems, each participant maintains a local copy of the synchronized data. That is, each synchronizing device (and intermediary such as the cloud 104) has a local copy of the configuration information that is to be synchronized. When one participant updates a piece of the configuration information, the update may be propagated to the other participants so that each participant's configuration information eventually substantially matches the configuration information on the other participants. Such synchronization updates are shown in FIG. 3 as layout and/or install updates 161, which may be carried by network packets. As explained below, some pieces of configuration information may be prevented from propagating by filters 162. Note that the arrows in FIG. 3 represent conceptual flow of information. In practice, the cloud may be an intermediary for updates; updates may flow from a user device to the cloud where they are applied/stored, and then the cloud may push the updates to other user devices as deemed appropriate.

Layout and/or install updates 161 (configuration updates) may stem from a wide variety of system events or user activities (for brevity, “install updates” in this Description and in the Figures refers to installing and/or uninstalling). For example, when a user initiates an application install 140 from the application service 108 to one of the user's devices, say first user device 100A, indicia of the installation is propagated among the user's devices and the cloud 104; each becomes aware of the application having been installed.

An application installation 140 or uninstallation might be initiated by the user selecting an application from a listing of available and/or purchased applications. The selecting and listing can be done locally with an application or client of the application service 108 running on a user device, for example a user may use an application launcher or GUI 116 to display indicia of available applications and to select applications for installation.

An application installation or uninstallation can be similarly initiated by a user accessing the application service 108, for example with a web browser, and by specifying an application and one or more user devices on which the application is to be installed or uninstalled. An application installation 140 can also be initiated automatically responsive to events on user devices or in the cloud 104. For example, an application installation 140 may be triggered when a new revision of an application is found to be available in the application service 108, when a version for a previously-unsupported platform becomes available, etc.

Application uninstalls may be similarly automatically triggered. For example, if a user's license for an application expires, the application service 108 may instruct the user's devices to uninstall the application. Application uninstalls may be initiated manually by any of the installation mechanisms mentioned above. In one embodiment, a GUI or an application launcher has a menu or list of installed applications that can be used to select applications for uninstallation. An application representation 128 may similarly offer a user interface element that when activated uninstalls the corresponding application (possibly with an option to specify whether the uninstall is local-only or global).

FIG. 4 shows an example system design for synchronizing configuration information among a user's devices. The first and second user computing devices 100A, 100B represent any two or more of the user's devices linked with a same user identity 114, or each such user device in a subgroup of the user's devices. The first and second user computing devices 100A, 100B may each have a synchronization client 180, configuration synchronization data 182 (layout and/or installation information), an application launcher 184, a set of installed applications 186, an application installer 188, and a local (unsynchronized) do-not-install list 190. In addition, the cloud 104 has a synchronization service with centralized configuration synchronization data 182C. These cloud and device elements may cooperate to perform processes 200, 202 that configure a user's computing devices so that the user has similar experiences when using the devices.

Process 200 may include sending to the synchronization service 192 layout/installation updates that occur locally. In addition, layout/installation updates may be received from the synchronization service 192. The received updates may cause the device to install or uninstall applications or to reconfigure a user interface provided by the application launcher 184.

Process 202 may involve the synchronization service 192 receiving configuration updates from within the cloud 104 (e.g., from the application service 108) or from the first and second user computing devices 100A, 100B. The process 202 may further include applying the updates received in the cloud 104 to modify the cloud-based configuration synchronization data 182C. In turn the updates, according to possible filtering or according to the source of the updates, are propagated to either or both of the first and second user computing devices 100A, 100B. Such updates may be propagated by sending the configuration synchronization data 182C en masse to the first and second user computing devices 100A, 100B, or by sending deltas (differences between device-based configuration synchronization data 182).

FIG. 5 shows examples of configuration synchronization data 182/182C (cloud or device based) and an example of a local do-not-install list 190. In some embodiments, as shown at the top of FIG. 5, the configuration synchronization data 182/182C includes indicia of application installs associated with a user identity and possibly further associated with subgroups of the user's devices. The configuration synchronization data 182/182C in effect identifies applications that have been installed on the user's devices, perhaps including installations on devices no longer associated with the user or including applications no longer installed on any of the user's devices. The configuration synchronization data 182/182C may also have information such as a timestamp when an application was installed, a timestamp when an entry was updated or added, etc. The data may also include information linking semantically equivalent applications; revisions or platform-specific versions of what a user may consider to be the same application (e.g., versions for different operating systems).

As shown in the middle of FIG. 5, in some embodiments, the application synchronization data 182/182C may include indicia of layout-related information, that is, information pertaining to layout, arrangement, or other properties of application representations, possibly within the application launcher 184. Generally, synchronized layout information may include user-configurations such as manually specified positions of application representations, types/categories of application representations, member groups, sizes, colors, and so forth. Synchronizable layout information is explained in greater detail above.

The example local do-not-install list 190 shown at the bottom of FIG. 5 functions something like a device-specific blacklist and contains indicia of applications that are not to be installed on the corresponding user device. The local do-not-install list 190 may have entries generated when a user indicated that an application was to be installed only from a device, for example using the device's application launcher 184. When uninstalling an application, the user may be given an option of uninstalling globally (from other devices) or only locally or only for a user-designated device. When an application is to be uninstalled only from a specific user device (or device group), the application may continue to be listed as an installed application associated with the user. That is, indicia of the application may remain in cloud-based and device-based copies of the configuration synchronization data 182/182C. In sum, an application listed in the copies of the configuration synchronization data may be automatically installed through synchronization on a user's devices that do not list the application in their respective do-not-install lists (possibly subject to further restriction by other mechanisms such as filtering).

In one embodiment, the configuration sync data 180/182 shown at the top of FIG. 5 (application installs) has an “uninstall” state that indicates whether corresponding application has been globally uninstalled. In other words, the top table of FIG. 5 may have a column titled “uninstall” that is marked for applications that have been globally uninstalled. Note any of the tables might have the application linking information such as the “same app” column shown in the top table of FIG. 5.

FIG. 6 shows an example of installation information synchronization. A chronological sequence is described with a first display 126A of the first user device 100A shown on the left and a second display 126B of the second user device 100B shown on the right. Starting chronologically from the top of FIG. 6, the user's two devices initially each have a same set of installed applications 186; app1-app4, app6, app8, and app9. The user performs a sequence of configurations, such as installing app7, installing app5 locally-only, uninstalling app9 local-only, and uninstalling app1. These application installation changes can be performed with any of the mechanisms discussed above. In this example, the changes are performed by the user using the application launcher 184 on the first user computing device 100A; other local or remote UI may be used, and some installations/uninstallations may result from automatic processes. For convenience, this example involves multiple installation changes over a short time span, however, the same or other installation changes could be performed in different orders and at different times.

In the case of installing application app7, the user may have interacted with the local application launcher 184 or an app-store type of application to select app7 for installing. The application launcher 184 of the first user device 100A may download data for installing “app7”. An entry indicating “app7” as an installed application is added to the local configuration synchronization data 182. The entry might be added by the installing software, or a synchronization component such as the local synchronization client 180 might detect the installation of “app7” and add the entry. The synchronization client 180 then forwards the update (new entry for “app7”) to the synchronization service 192, which adds the new entry for “app7” to its configuration synchronization data 182C.

When the synchronization service 192 next synchronizes with the second user device 100B, the update for “app7” is sent to the synchronization client 180 of the second user device 100B, which updates its copy of the configuration synchronization data 182. The application installer 188 or other system service on the second user device 100B detects or receives notice of the update, reads its copy of the configuration synchronization data 182, identifies “app7” as needing to be installed, and in the background downloads and installs “app7” from the application service 108. In one embodiment, as shown in the lower right part of FIG. 6, while application “app7” is installing or scheduled for installing, a place-holding application representation 128A for “app7” has some graphic properties to indicate that the application is not yet installed; a progress bar; transparency, a designated color or symbol, etc. The place-holding application representation 128A can perhaps be partially configured (e.g., moved, resized, added to a group) and those changes might also be synchronized to corresponding application representation on the first user device 100A.

In the case of the local-only install of app5 at the first user device 100A, app5 is installed from the cloud 4 and added to the do-not-install list 190 of the first user computing device 100A. This may result from either the user having specifically designated the installation as local-only, or from the first user device 100A having determined that synchronization is not appropriate for app5 (e.g., found that app5 has a hardware or software feature or requirement that limits is applicability to other devices). The presence of app5 in the local do-not-install list 190 prevents app5 from being added to the configuration synchronization data 182; the user's other devices are not informed of the installation of app5.

In the case of the local-only uninstall of app9 on the first user device 100A, app9 is uninstalled only on the first user device 100A and is added to the do-not-install list 190 on the first user device 100A. If app9 was listed in copies of the configuration synchronization data 182/182C it may remain therein; app9 may continue to be install-synchronized on the user's other devices.

The global uninstall of “app1” at the first user computing device 100A flows through the synchronization components to the cloud 104 and to the second user computing device 100B, causing application “app1” to be background-uninstalled at the second user device 100B.

The appearance of the application launcher 184 on the second user device 100B is shown at the lower right corner of FIG. 6 and corresponds to which applications are installed and not installed on the second user computing device 100B. Note that application install/uninstall synchronizations need not be accompanied by user interface or layout updates such as to the application launcher 184.

To summarize, applications can be installed and uninstalled on one of a user's devices and automatically installed and uninstalled on other of the user's devices that are inter-linked for synchronization (inter-linking can be automatic based on a common user identity). In some cases, applications can be excluded from synchronizing using local do-not-install lists. Application installs indicated by received synchronizations are not installed if listed in the local do-not-install list, and applications in the local do-not-install list are not synchronized to the cloud 104.

FIG. 7 shows an example of layout information synchronization. At the top of FIG. 7 the first and second user devices 100A, 100B initially have a layout of application representations, for example in the application launchers 184. The user interacts with the application launcher 184 at the first user device 100A to create group3 200, move the app3 representation to group3, reorder the app1 and app2 representations, change the color of the app2 representation, remove the app4 representation, and resize the app1 representation. In one embodiment, the changes are applied to a configuration file or other non-volatile set of configuration data used by the application launcher 184. The local synchronization client 180 detects the changes and propagates them up through the cloud 104 to the second user device 100B, where the changes are synchronized to the configuration file/data used by the second device's application launcher 184. The application launcher 183 reads its configuration file/data and updates its layout accordingly. As shown in FIG. 7, the layout of the application launchers 184 eventually match one another, perhaps with some differences attributable to differing sizes or resolutions of the first display 126A and the second display 126B (there is no requirement that synchronized user devices have any hardware equivalences; synchronized user devices may have different architectures, display sizes, etc.). In some cases synchronized layouts may not have the same exact appearance due to factors such as different screen sizes, differing sets of installed applications, or others. A flow layout approach may be used to reproduce some aspects of a layout, such as the relative order of application representations, as shown in the example of FIG. 7.

As mentioned above, synchronizing devices and the cloud 104 might have filters 162 to prevent certain updates from synchronizing. A filter 162 can prevent updates from being applied or from being forwarded. For example, at the cloud 104 application installs might be filtered out for devices that are incompatible or do not have license or authorization, for example. Filtering can be performed on any of a variety of factors such as application attributes, licensing information, user device attributes, software or hardware requirements, user preferences regarding synchronization, or others.

When a second or later device becomes associated with a user, perhaps by enabling synchronization or by adding the user's network identity to the second device, the device might immediately begin synchronizing immediately or when the user logs in to the later device.

Regarding the synchronization of application installations, when multiple application installs are queued by a user device per synchronization updates, the order of installation can be prioritized according to factors such as which applications are most recently used on the source user device, the order applications appear in the application launcher of the source user device, order of installation on the source device, frequency of use of the application on the source device and/or other devices, user ratings, etc. In addition, lack of resources such as bandwidth or storage on a user device may delay or prevent some installations. When some applications cannot be installed due to insufficient space, installation prioritization (which applications will or will not be installed) may be similarly determined.

Configuration updates that are to be synchronized might carry with them a timestamp indicating when the update at a source. The timestamps may be used to resolve conflicts between updates, generally with later updates superseding conflicting earlier updates.

As noted above, a synchronization system can be designed to account for application incompatibilities. When an application is available for incompatible platforms or user devices, the synchronization system might propagate installs of an application intelligently to only the devices where the application can execute. In addition, continuing indication of an application as being installed can be repeatedly ignored or blocked at or for incompatible user devices but when a compatible version becomes available (or a device becomes compatible) the compatible version is automatically installed for the corresponding user device, perhaps much later than the first time the application was installed by the user. In this way, even when the user has incompatible devices, respective versions of the same application might be automatically installed via synchronization.

A user device might also be equipped with logic to detect, when an application is being installed, whether the application has device dependencies (hardware and/or software) that indicate the application might not function or have use at other devices. Such applications might be automatically excluded or filtered from synchronizing. If another user device changes and begins to satisfy the dependency, the application might then be synchronized to that device.

As mentioned above, the synchronization techniques can be readily extended to groupings of a user's devices and to groupings of applications. For example, the user might designate two devices as “work” devices and three devices as “personal” devices. The grouped devices synchronize among themselves. A global group may also be used. Applications or devices may be added to or excluded from multiple groups. In one embodiment, the user is allowed to specify particular application groups in the application launcher as being synchronized or not, which might control either or both layout and install synchronizations that affect the groups. In effect, the user might have one portion of UI layout designated for synchronization and another portion designated as not to be synchronized.

In yet another embodiment, a user's application layout and installation information is stored in the cloud 104 even when there are no longer any devices associated with the user. If the user then associates a device with the user's identity, the stored cloud information is automatically synchronized to the new device and the device begins to install applications and configure layout according.

Regarding local do-not-install lists, if a user manually installs an application on a device that lists the application in its do-not-install list, the application may be removed from the do-not-install list on that device.

A preview application representation can be displayed when a user has exceeded a number of devices permitted to install a given application. That is, there may be an indication to the user that an application would be installed per synchronization but for the fact that the application lacks a license. When the user selects the preview application representation, the user may be notified that a device limit has been exceeded and may be given guidance or access to a means to remedy the situation, for example by removing the application from one of the user's devices.

Synchronization might be able to be manually disabled by the user on individual devices or globally. Similarly a group policy control might be provided to allow administrators to regulate synchronization implementation.

FIG. 8 shows an example of a computing device 100 on which embodiments described above may be implemented. The computing device 100 may have one or more displays 266, as well as a storage device 262 and a processor 264. These elements may cooperate in ways well understood in the art of computing. In addition, input devices 268 may be integrated with or in communication with the computing device 100. The display 266 may be any variety of devices used to display a signal outputted by computing devices, including, for example, solid-surface displays (e.g., plasma, liquid crystal), projectors, touch-sensitive surfaces, and others. The computing device 100 may have any form factor or may be incorporated in another device. For example, touch-sensitive control panels are often used to control appliances, robots, and other machines. The computing device 100 may be in the form of a handheld device such as a smartphone, a tablet computer, a gaming box, a headless server, or others.

Embodiments and features discussed above can be realized in the form of information stored in volatile or non-volatile computer-readable or device-readable devices. This is deemed to include at least devices such as optical storage (e.g., compact-disk read-only memory (CD-ROM)), magnetic media, flash read-only memory (ROM), or any other devices for storing digital information in physical matter. The stored information can be in the form of machine executable instructions (e.g., compiled executable binary code), source code, bytecode, or any other information that can be used to enable or configure computing devices to perform the various embodiments discussed above. This is also deemed to include at least volatile memory such as random-access memory (RAM) and/or virtual memory storing information such as central processing unit (CPU) instructions during execution of a program carrying out an embodiment, as well as non-volatile media storing information that allows a program or executable to be loaded and executed. The embodiments and features can be performed on any type of computing device, including portable devices, workstations, servers, mobile wireless devices, and so on. 

1. A method performed by a network service, the network service comprising an application repository service, the method comprising: maintaining a set of user accounts by a user account service accessible via a network by devices associated with the user accounts, wherein the user accounts are authorized to install applications from the application store service, wherein the user account service maintains device lists for the user accounts, respectively, wherein each device list lists whichever devices are linked to a corresponding user account, and wherein the maintaining comprises adding and removing devices to the device lists; providing an application store service comprising a database storing application install packages, application identifiers, and associations between the application install packages and the application identifiers, wherein some of the application identifiers each have associations with multiple application install packages that are configured for different and incompatible operating systems, the database further storing, for each user account, each application install list listing, for a respective user account, application identifiers of respective applications that have been installed in association with the respective user account; and providing a synchronization service that synchronizes application installations according to the device lists and the install lists such that when a device list lists two devices with different and incompatible operating systems, an application identifier in the corresponding install list is applied to the associations to select application installation packages specific to the operating systems of the two devices, respectively, for installation thereto.
 2. A method according to claim 1, wherein the synchronizing causes an application that is to be synchronized to devices in a device list to be synchronized by selecting application packages according to the operating systems of the devices in the device list.
 3. A method according to claim 1, further comprising updating the device lists to reflect associations and disassociations of devices with user accounts, wherein when a device becomes associated with a user account, the applications identifiers in the corresponding install list are used to select corresponding application packages according to an operating system of the device.
 4. A method according to claim 1, further comprising updating the application install lists to reflect additions and removals of applications associated with the user accounts, wherein when an application is added to an application install list, a corresponding application install package is selected for a device in the corresponding device list based on compatibility with an operating system of the device, wherein application install packages are synchronized to the user devices according to compatibility with the operating systems of the user devices.
 5. A method according to claim 1, wherein when the synchronization service determines that an application of a corresponding application identifier is not installed on a user device and a corresponding application list indicates that the application is to be installed to the user device, an application install package is selected based on an association thereof with the application identifier and based on a determination that the application install package matches an operating system of the user device.
 6. A method according to claim 5, wherein the synchronization service responds to removal of an application identifier from an application list by signaling user devices in the corresponding user device list to uninstall the application, wherein the signaled user devices have different and incompatible operating systems.
 7. A method according to claim 6, wherein the signaled user devices remove different respective install packages of the application that are respectively for the different and incompatible operating systems.
 8. A method of synchronizing software installations between devices, the method comprising: providing application packages of applications from an application installation service, each application associated with one or more application packages, wherein some applications each have associated therewith application packages for different and incompatible operating systems, the application installation service comprising a network-based service that: stores the application packages for installation to user devices, tracks which applications are associated with which user identities, and accesses user identities and user device associations indicating which user devices are associated with which user identities; accessing groups of synchronization settings, the groups associated with the user identities, respectively, wherein each group of a corresponding user identity comprises synchronization settings for respective applications associated with the corresponding user identity, each synchronization setting indicating whether a corresponding application is to be synchronized among the devices associated with the corresponding user identity, and wherein the groups are updated to reflect installations of applications to the user devices via the application installation service; and using the synchronization settings to automatically control installations of the application packages to the user devices, the using including: whenever any synchronization setting is modified to indicate that a corresponding application is to be installed on all user devices of the corresponding user identity: automatically determining that two user devices associated with the corresponding user identity do not have an application package of the application installed and signaling for installation of one or more application packages of the application to the determined user devices, selecting the application packages for installation to the determined user devices by identifying operating systems of the respective determined user devices and selecting the application packages accordingly, wherein the selected application packages are for the different and incompatible operating systems of the respective determined user devices, and automatically initiating installation of the selected application packages to the respectively corresponding determined user devices.
 9. A method according to claim 8, further comprising maintaining associations between applications and application install packages and storing operating system identifiers that identify which operating systems the application install packages are for.
 10. A method according to claim 9, wherein application packages for a same application are selected for installation based operating systems of corresponding user devices that are associated with a same user identity.
 11. A method according to claim 8, wherein synchronization of application installs between devices linked to a same user identity are performed based on the identifying the operating systems.
 12. A method according to claim 8, wherein when multiple applications are to be installed on the user device according to the global application synchronization information, the user device prioritizes an order of installing the multiple applications.
 13. A method according to claim 8, wherein when an application is uninstalled at a first user device linked to a user identity user device, uninstall of the application is synchronized to a second user device linked to the user identity, wherein the first user device comprises an operating system that is incompatible, for applications, with an operating system of the second user device.
 14. A method according to claim 8, wherein the method is performed by a management service that comprises the application installation service, a user account service, and a synchronization service, the synchronization service automatically providing application installation and uninstallation synchronization service between user devices that are associated with a same user identity.
 15. A method according to claim 14, wherein the application installation service tracks associations between operating system types and application packages.
 16. A method according to claim 8, further comprising accessing user settings of the user identities, respectively, each user setting indicating which user devices of an associated user identity are or are not subjected to automatic application installation synchronization. 